ELECINF344/381

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

Catégories

Wireless RoseWheel

After a long night of debugging, we finally managed to make the bluetooth working.  We are now able to send instruction and receive information from RoseWheel through the bluetooth interface using minicom on a laptop. We are also able to pair with an Android smartphone but we haven’t been able to verify the data transmission yet. We are still working on the Android application, but hopefully tomorrow we will be able to start our first tests of wireless communication with RoseWheel.

We also tested the  range of the Bluetooth with the transmitter inside the chassis and we received the signal from a distance of approximately 10 meters with two walls in between.

We started the implementation of the human-interface board. We have found a big LCD driven by the same controller as the one of our laboratory boards. We plan to use it to display information to the user directly on the handlebars, such as the engine power, battery level and the current angle measured by the sensors. As we are going to place the LCD vertically we had to rewrite a new set of characters made to be displayed in this orientation.

RoseWheel: first ride

Tuesday evening, after nearly two days of fine-tuning our testing procedures and security measures, we finally did the first tests on our own vehicle. In order to make sure we didn’t damage the equipment (nor hurt somebody), we followed a simple and strict protocol:

1. First of all, we checked that we could control manually the motors via our interpreter;

2. Then, we verified that the limitations we applied to the variation of the voltage of each motor were adequate (as mentioned in a previous post, an abrupt increase or decrease on the voltage could severely damage the motors);

3. Finally, we determined a maximum speed that seemed reasonable, so that we could stop the vehicle manually should the worst happen.

After this initial procedure, we could start the actual tests of our system. After some iterations of tuning the coefficients of our controller, we realized that it was actually much easier to equilibrate the vehicle with a human being on top of it than without any load, since:

(i) the person enhances the performance of the control system by balancing his/her weight in a way that maximizes stability;

(ii) the presence of the human being makes the test conditions closer to the physical model we used to compute and simulate the parameters.

After several adjustments, we were able to take our first ride on the RoseWheel -- with basic steering capabilities via the integrated potentiometer implemented as a plus.

Nevertheless, by wednesday morning we had not yet found a way of balancing the RoseWheel alone -- a must for our next major goal, remote control. Then, we realized that the chassis we used had a very interesting property: by tilting it to a specific angle, we could align the center of gravity of the steering bar with the axis of the wheels, reaching a metastable equilibrium. We used this fact to offset the error variable of our PID controller, and that proved to be very effective, since we obtained as a result a pretty good stability. But all this comes at a price: since we now have two different equilibrium positions, we must use the safety button located on the chassis to determine if we are carrying a person or not; nothing too difficult to implement, though.

On the other hand, the PID coefficients may be trickier to master. We are still working on them to solve the issues we are having, notably oscillations and vibrations that sometimes occur. To help us with the debugging, we set up a solution to plot angle, angular velocity, and output voltage command for each one of the motors. Our next actions on this front will be to use all these data to better tune Kp, Ki and Kd, so as to have a more responsive and stable control algorithm.

Meanwhile, we started to move on to our next goals: we began to study the Bluetooth controller, and are already able to compile and run a « hello world » Android application. Next steps include implementing drivers for our distance sensors to implement obstacle detection.

To summarize all our work, we prepared a special video showing some of the most interesting (and/or funny) demos we made so far. Enjoy!

 

[CASPER] Reconnaissance vocale et synthèse

Bonjour à tous.

Comme vous le savez déjà pour la plupart, nous avons montré Mercredi que nous étions désormais capables d’effectuer une reconnaissance vocale performante en Anglais, en utilisant la librairie CMU Pocketsphinx.

Cette librairie permet la reconnaissance de phrases complètes, ce qui permet de bénéficier d’une bonne qualité de détection en prenant mieux en compte la nature du langage. Afin d’améliorer la détection des commandes, nous avons généré à partir des outils fournis avec pocketsphinx un dictionnaire et un modèle de langage qui ne contiennent que les mots dont nous avons besoin.

Nous souhaiterions générer ce type de dictionnaire/modèle de langage pour le Français, ce qui s’avère plus compliqué étant donné qu’il n’existe pas encore d’outils réalisant ce travail.

 

En ce qui concerne la synthèse vocale, notre choix s’est porté sur l’excellente librairie SVOX Pico, qui fait déjà ses preuves sur les téléphones Android (avis aux amateurs voulant l’essayer).

La voix est, en comparaison avec d’autres solutions libres, naturelle et fluide. Cette bibliothèque supporte l’anglais (US et GB), l’allemand, le français, l’espagnol et l’italien. Nous avons à présent un Hello world fonctionnel qui synthétise la voix correspondant à un texte (stocké en dur dans le code pour le moment) et qui envoie les échantillons directement à pulseaudio pour une lecture sur haut parleur.

Cette bibliothèque nous laisse entrevoir la possibilité de lire des messages dans les 5 langues précédemment citées, ce qui pourrait donner une valeur ajoutée intéressante au projet.

 

Il nous reste à porter tous ces programmes sur la beagleboard et mesurer leurs performances respectives, en terme d’occupation mémoire et de temps de calcul.

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.

MB Led: Article post communication challenge.

Aujourd’hui j’ai enfin réussi à flasher quatre modules conçus par l’équipe GLiP de l’an dernier. J’ai flashé le code maitre pour un bloc contrôlable avec un PC et minicom pour la sélection des animations ainsi que le code pour trois esclaves.

Lors de la compilation de ces codes sont incluses les différentes animations préalablement convertis grâce au script python gif2glip (conçu par l’équipe GLiP).

Nous avons donc pu faire tourner des petites animations sur un réseau carré de quatre GLiP tout en constatant que les animations étaient bien affichées après mélange des blocs.

Cette étape m’a permis de me familiariser avec l’architecture du code de GliP et de m’imprégner de leurs algorithmes pour la réorganisation du réseau ainsi que pour l’affichage des images via les drivers de LED. La compréhension de ce code nous permettra de faire des premiers tests notamment pour les communications IRDA et nos algorithmes réparties en attendant d’avoir nos propres modules.

Ce soir je me suis consacré à la réorganisation de nos PSSC et à la création d’un diagramme de Gant pour une meilleur répartition des ressources dans notre équipe. Le temps passé sur le TP sur le STM32 nous a obligés de décaler les différentes deadlines pour nos PSSC.

====== Reprise du projet GLiP : ======
- A partir de GIF convertibles par gif2glip nous savons les charger via le bloc maître et les jouer sur un réseau de bloc en utilisant leur matériel ⇒ Fait

====== Conception de la carte et test : ======
- Choix des composants terminé : Fait

- Image PCB prête (on peut passer la commande du circuit imprimé) ⇒ 25 mars

Puis en supposant que nous recevons les PCB au plus tard le 4 avril :

- Soudage des composants sur les cartes => 6 avril

- Contrôle de la matrice de LED (affichage d’image) ⇒ 15 avril

====== IRDA ======
- Echange de messages entre deux blocs ⇒ 11 avril

- Ecriture via Irda sur la sdcard => 22 avril

====== Bluetooth: ======
- Communication Bluetooth avec un ordinateur ⇒ 16 avril
- Exécution de commandes reçu en Bluetooth ⇒ 21 avril
- Application de contrôle Android ⇒ 26 avril

====== Gestion de la mémoire : ======
- Lecture sur la SD Card. ⇒ 12 avril
- Ecriture sur la SD Card. ⇒ 17 avril
- Exécution d’un programme stocké en SD Card. ⇒ 22 avril
- Mise à jour du firmware depuis la SD Card. ⇒ 24 avril

====== Système réparti : ======
- Environnement de simulation en place ⇒ 3 avril
- Gestion dynamique du réseau de bloc⇒ 15 avril

====== Jeux sur l’ensemble : ======
- Jeu du morpion fonctionnel (sans Bluetooth) ⇒ 24 avril
- Jeu du morpion fonctionnel (avec Bluetooth) ⇒ 27 avril

 

Rosewheel restructure son planning

Aujourd’hui nous avons pris le temps de réétudier un peu notre planning. Les travaux pratiques de l’UE ont, pour les premières semaines, un peu empiété sur le temps que nous voulions consacrer au projet et quelques modifications s’imposent. Nous pensons néanmoins être toujours dans les temps par rapport à nos objectifs finaux. Notre planning prévisionnel était :

  1. Étude : Kalman, composants, banc de test
  2. Conception PCB : logique, capteurs
  3. Contrôle en vitesse non asservi
  4. Fusion de capteurs & asservissement
  5. Tenir debout, tourner, s’arrêter
  6. Détection d’obstacles
  7. Conception & implémentation contrôle brushless
  8. Conception de l’application Android & video
  9. Soutenance finale

L’étude du filtre de Kalman en première semaine a été concluante. Nous disposons de tous les éléments théoriques pour concevoir le filtre optimal pour notre application. Afin d’assurer un bon équilibre entre robustesse du filtre et complexité des calculs, différentes approches, complémentaires, sont mises en place. Tout d’abord, afin d’assurer la robustesse du filtre aux erreurs numériques susceptibles de se produire du fait de l’utilisation de calculs en virgule fixe, nous comptons utiliser l’algorithme du square root filtering. Ensuite, nous séparerons bien les capteurs entrant dans l’équation d’évolution du système et les capteurs n’ayant un rôle que de « mesure », ceci afin d’alléger la taille des matrices utilisées dans le filtre. Enfin, nous nous placerons dans la situation, fictive, où RoseWheel est toujours immobile. Le mouvement de ce dernier sera vu comme un bruit que nous intégrerons dans les équations et qui, si le choix des différents paramètres est judicieux, nous permettra là aussi d’obtenir des résultats satisfaisant tout en garantissant la simplicité des calculs.

Une étude plus approfondie de la dynamique du système nous a également permis de définir plus précisément nos différentes unités de traitement : filtre Kalman pour supprimer le bruit des capteurs, LQR pour asservissement en inclinaison, LQR pour asservissement en vitesse des moteurs brushless. Il nous manque toujours certaines informations pour pouvoir établir des modèles notamment des informations sur les divers éléments mécaniques et les capteurs. Nous n’avons pas encore finalisé le choix des capteurs et autres composants que nous allons utiliser. Nous avons collecté suffisamment d’informations sur ces derniers mais nous devons maintenant trancher en fonction de plusieurs contraintes : coût, précision, bruit de mesure, disponibilité, délais de livraison, possibilités de collaboration… Par exemple, nous pourrions partager les efforts avec Copterix pour les accéléromètre (MMA7660FCR1), gyroscope (IMU-3000) et capteur sharp (GP2Y0D02YK0F) de façon à factoriser les développements. Mais nous pourrions aussi utiliser des composants plus appropriés comme ce qui a été proposé à la soutenance initiale (nous n’avons par exemple pas besoin de 3 axes pour le gyroscope). Nous allons affiner notre sélection durant les prochains jours pour converger vers un choix final au plus tard samedi prochain (justifications à l’appui) de façon à pouvoir finir les PCB logique et capteurs pour dimanche soir comme prévu..

La première semaine devait également faire l’objet d’une étude sur la réalisabilité d’un banc de tests pour nos capteurs. Suite à plusieurs fausses pistes nous avons finalement trouvé où nous procurer des servos et du bois/plexi. L’implémentation, assez triviale, a bien avancé. La réalisation du banc de test reste tout de même moins prioritaire que l’avancée sur les capteurs et le filtre de Kalman : il est inutile de tester quelque chose que l’on a pas encore conçu. Nous avons donc décidé de reporter la semaine 3, soit la semaine prochaine. Nous devrions avoir un prototype viable en fin de semaine.

Enfin nous avons pris un peu de temps pour développer un simulateur simple de la physique de notre système (pour l’instant tel que décrit dans la thèse de Rich Chi Ooi) à l’aide d’Octave. Cela nous permettra de faire des premiers tests sur le filtre de Kalman et le (les) LQR assez rapidement.

RoseWheel : le retour !

Après une semaine bien dense pendant laquelle certains ont pu travailler sur Kalman et d’autres sur LQR, nous avons aussi avancé dans notre recherche de composants mais il reste encore quelques incertitudes.
Sachant que nous allons partager nos efforts avec Copterix pour les tests des gyroscope et accéléromètre, nous allons prendre les mêmes qu’eux.
Un bon schéma vaut toujours mieux qu’un long discours, voilà donc l’architecture de notre système :
Schéma RoseWheel-AndroWheel

Architecture du projet

 

Pour télécommander notre RoseWheel Nous utiliseront probablement le bluetooth puisque c’est sur tous les téléphones. Nous avous estimé que du bluetooth 2.0 (~1.4MB/s) class2 (portée ~10m) devrait largement suffire pour une première version. De plus, nous aimerions vraiment implémenter un retour vidéo mais ça va dépendre du temps qu’il nous reste.

Si le temps se fait rare, nous pourrions envoyer la vidéo au téléphone sous android grâce à une « caméra wifi » de ce genre :

http://www.bewan.fr/entreprise.php?page=entreprise&parm1=presse&parm2=communique&id=47

=> Nous l’avons trouvé à 56€ ici :

www.cdiscount.com/informatique/materiel-reseau-wifi-internet-bluetooth/bewan-icam-100n-bwbc-100n/f-10715290802-bwbc100n.html

Si nous n’arrivons pas à connecter la caméra directement au téléphone, cette solution impliquerait de passer par un routeur, de streamer la vidéo sur un serveur et de s’y connecter avec l’android.
Si cette solution ne marche pas non plus, nous pensons utiliser une beaglebord ou une gumstix pour y brancher une caméra et envoyer la vidéo au téléphone sous android.

Nous avons plusieur solutions :

- par bluetooth 3.0 (24Mb/s) avec un dongle usb pour une vingtaine d’euros en plus (Nous pourrons utiliser le samsung galaxy S qui  a le bluetooth 3.0 mais sinon c’est rare)

- par wifi, plus démocratisé, mais c’est plus compliqué à utiliser.

La beaglebord a l’avantage d’embarquer un DSP et du wifi mais même si c’est moins cher, c’est bien plus gros qu’une gumstix.

Nous verrons plus tard les codecs de compression vidéo utilisables mais à priori ça suffit largement. Nous devrons donc faire tourner un petit linux dessus ce qui fera grand plaisir à certain d’entre nous ;)

Nous avons également étudié plus en détail la physique du système.
La thèse de Rich Chi Ooi présente un modèle physique assez complet décrivant un gyropode comme une combinaison de trois sous-systèmes : les moteurs, les roues et le chassis.
Nous avons donc refait les calculs pour être surs de les avoir compris et pour éclaircir les points sur lesquels l’auteur passe rapidement.
Par ailleurs ce dernier donne une modélisation intéressante des moteurs à courant continu mais le principe physique des moteurs brushless étant différant, nous devrons peut être réfléchir à un modèle plus approprié.
La modélisation de notre système sous la forme x’= Ax + Bu nous permettra prochainement de mettre en application le cours sur le LQR donné vendredi par nos collègues.

C’est parti pour MB Led

Hier et aujourd’hui, nous sommes partis du projet GLiP et avons pensé à des évolutions.

Nous espérons avoir les nouveaux blocs qu’Alexis a conçu, sinon il nous faudra le faire nous-même. Nous avons étudié la structure de GLiP en cas de conception de blocs. Nous repartirons sur un STM32, cependant nous regardons si nous ne trouvons pas un controleur avec une plus grande mémoire.

Nous voulons que le nouveau projet puisse lire des informations envoyés en Bluetooth par un smartphone de type Android. Ainsi, nous allons créer un module Bluetooth – Infrarouge. Pour cela, nous avons choisi le module Bluetooth F2M03GLA utilisé l’an dernier par le projet Wheely. Ce bloc ne posséderai pas de contrôleur et l’ensemble du traitement des données envoyées et reçus se feront sur la machine externe en soft.

Autre nouveauté : nous aimerions nous passer d’un maître dans les interactions entre blocs. Il faut concevoir des algorithmes d’échanges d’information en système réparti. Nous étudions actuellement les différentes possibilités.

Enfin, nous avons prévu les étapes, le planning et la liste des critères de succès finaux.