ELECINF344/381

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

Catégories

[CASPER] New video

We posted a new video showing our group performing with casper :

- Video tracking

- Dancing

- Mail fetching

- Vocal commands

 

MB Led : Visual display of algorithm and snake first steps

Since our last post, Guillaume is still on the algorithm. Benjamin developed a display task for the old and new GLiPs. Now, we can see directly what’s going on in the network and try to debug it (see the picture). Yesterday, Guillaume tried to resolve bugs of freezing GLiP while the algorithm is running. He had to change many things in order to fix this and the only remaining freeze happens when some blocs leave the network.

There are some troubles when a block isn’t gone but don’t communicate with his neighbors. The biggest problem is when a block is rickety and that he communicates for time to time : he is considered as gone and soon after, he is here, etc. When this happens, the network can fail.

 

 

A little video to illustrate the visual debug:

 

Benjamin is develloping a special snake game concept for our system.

 

Guillaume and Benjamin.

 

IRL: the riddle with a mere oscilloscope!

Yesterday we achieved a new goal : we successfully played an ILDA animation on a mere oscilloscope. We attach a video as an evidence of our performance.

Let’s focus on what we actually did.
We built a program which plays directly an ILDA animation in the ILDA file format. We can set several options directly on the command line such as the time spent per frame and the scaling factor.

We enhanced our code which built an ILDA file from a string or a file. It operates directly on board and is now using an ILDA file per character instead of a SVG file with the whole charset.
We display directly on the board a list of tweets taken from a database and fetched them on the go with the twitter API that we now use in C instead of Python.

The IRL project would be nothing without those huge changes that drew our path since the beginning of the project. And we are proud to announce that we are changing (again) our architecture, and we would like to thank our teachers for their precise suggestions on that topic. In a word we are going to rely on a wishbone bus so as to assure the communication through the entities of the FPGA. In that way, out system will be cleaner plus it will enhance its capabilities.

[CASPER] New video about Mechanical advances

This week-end we added a new video showing how we are able to control Casper’s direction and bending remotely. Movements are smoother and have a good response time.

Now, that we got a UART connexion working on the BeagleBoard we will be soon trying to use it to control Casper.

RoseWheel: tests preparation

This week we tried to put together our developments and make them interact with each other. It includes sensors communication, kalman filter, control feedback, motors control, CAN communication protocol. We were dogged by bad luck as we realized the heatsink of our mainboard was too big to fit in the Zzaag… A few millimeters required us to order for a new one with a more suitable shape. Fortunately Alexis and Samuel helped us to find a new one. Because of that we were not able to validate the following « feedback control tuning » PSSC for Saturday as planned. Adviced by Samuel we also decided to postpone the « encoders drivers » PSSC as it wasn’t really in our first order priorities.

 

We tried to make profit of this situation and decided to prepare everything for the first tests. Alexis helped us defining our tests procedure to be as safe as possible for both hardware and people. Motors need special attention as they can be broken with unsuitable commands. Because of the wheels and the weight of the chassis they have a really high inertia. Asking them sharply to reverse their direction of rotation when they are rotating fast can seriously damage them and the H-bridges. If we damage them we wouldn’t be able to order new ones before the end of the course, it would be fatal for our project. Therefore we need at first to make some testing at low speed so as to define the maximum acceptable speed at which we can run the motors before they get damaged. To this extent we need an interpreter running on the mainboard and communicating using RS232 to be able to give motors various commands and define this maximum speed. Then we need to limit our commands to this maximum speed using software limitations. Finally the interpreter should be able to change the feedback control values for our testing to be more flexible. We implemented such an interpreter and made a video. The motors commands in the video are given between 0 and 1000 such as:

  • ml0 = 0%:  max negative speed
  • ml500 = 50%: stop
  • ml1000 = 100%: max positive speed

 

Before trying the Zzaag motors we do some testings on other DC motors with less inertia that we cannot damage as easily as the Zzaag’s ones. Putting all the pieces together we were able to shoot a video which shows the motors reacting appropriately to the inclination of the sensorboard. As for the Kalman filter, we implemented a lighter version than the one of RoseWheel as it works best when tested on the real system. This version was only able to track the gyroscope drift and correct it. As far as we could see during the testing, it did it well. Concerning the PID, we tried to test the version that we are going to use in the RoseWheel but it still needs to be improved during the next tests.

 

Tomorrow we will be able to work on the Zzaag motors using our safe procedure and the tools developped. We look forward to it as it is a major step further for our project…

[CASPER] Prototype fonctionnel

Hier, nous avons finalisé le prototype mécanique.

Nous avons installé les trois servomoteurs sous le plan du socle. Nous les contrôlons grâce à un signal PWM de la carte de TP STM32.

Nous avons changé nos anciens câbles de carbone par des câbles en plastique. Il est apparu que bien que leurs propriétés mécaniques en poussée/traction étaient bonnes, celles-ci ne sont pas assez flexible pour supporter les mouvements au niveau des bras motorisés.

Nous avons implémenté un programme de commandes qui fait effectuer un 360° à Casper que nous contrôlons par le potentiomètre (relié à l’ADC) de la carte de TP.

Nous allons maintenant travailler sur des fonctions qui permettent un contrôle précis de la direction et de l’inclinaison de Casper et en parallèle peaufiner le prototype afin qu’il soit plus robuste.

Voilà la vidéo du programme de démonstration (360° contrôlé par ADC) :

 

Parallèlement, l’UART sur le PCB est fonctionnel et on peut pour l’instant afficher les chaînes de caractères reçues sur l’écran LCD.

Copterix : finalisation du filtre de Kalman

Alors, comme nous l’avons dit hier, cette journée a été dédiée aux tests du FQA et du filtre de Kalman sur une IMU. On récupère les données brutes des capteurs (3 gyroscopes, 3 accéléromètres et 3 magnétomètres) par un script python. Le Kalman qui sera implémenté sur la Gumstix est en C++. Il a donc fallu dans un premier temps faire communiquer le script python et le programme C++ afin d’acheminer les données des capteurs vers notre Kalman. Nous avons pour cela utilisé ZeroMQ avec une architecture Publisher/Subscriber.

Une fois la communication fonctionnelle, nous avons pu commencer à tester notre FQA et notre Kalman. Au début, nous avions pas mal de problèmes au niveau de l’orientation de nos axes. Mais après avoir passé pas mal de temps à étudier les sorties des capteurs pour comprendre selon quels axes ils étaient positionnés, nous avons obtenu des résultats plutôt satisfaisants :

Dans la première vidéo , nous n’utilisons pas le filtre de Kalman (juste le FQA) alors que dans la seconde, le filtre de Kalman est activé. L’utilisation du filtre permet d’éliminer pas mal de bruit. Il reste tout de même quelques petits détails à régler car il y a quelques indéterminations qui chamboulent un petit peu le filtre.

Nous avons en outre reçu notre PCB :

La journée de demain sera consacrée à établir la communication avec notre nouvelle carte !

[CASPER] Premiers contacts avec PocketSphinx et OpenCV

Aujourd’hui nous avons poursuivi l’exploration des bibliothèques de traitement vidéo et audio.

Partie Audio : La bibliothèque que nous utilisons s’appelle PocketSphinx. Nous sommes aujourd’hui capable de reconnaître des mots ou des phrases en anglais et de les associer à des commandes (appui sur une touche clavier ou ouverture d’un fichier par exemple). La prochaine étape est de faire fonctionner un synthétiseur vocal.

Partie Vidéo : La bibliothèque que nous utilisons s’appelle OpenCV. Nous avons écrit un programme qui récupère un flux vidéo de la webcam et détecte dans chaque frame la présence d’un visage ou non. Si il en trouve un, il l’encadre. On peut observer la détection dans une fenêtre qui affiche les frames au fur et à mesure de leur traitement. La prochaine étape est d’implémenter l’apprentissage et la reconnaissance de visages.

Enfin, nous avons préparé la soutenance intermédiaire de demain.

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.

Architecture logicielle de Copterix

Aujourd’hui, après m’être renseigné sur 0MQ, pour le dialogue entre les différents modules de notre futur Copter, j’ai essayé de fixer l’architecture logicielle qu’on pourrait utiliser, à travers un schéma. Le voici, suivi de quelques explications :

 

Le STM32, qui fonctionnerait sous FreeRTOS, est directement relié aux capteurs et actionneurs de la carte. Ceci est nécessaire, notamment pour l’acquisition des données fournies par les capteurs : le filtre de Kalman nécessite que les données de tous les capteurs soient acquises presque en même temps. Il nous faut donc du vrai temps-réel, d’où l’intérêt du STM32 sous FreeRTOS.

 

Tournant sur la Gumstix :

Un module serait dédié aux communications avec le STM32 via l’UART. Ce module ferait des updates régulières des données des capteurs pour le filtre de Kalman, via les bibliothèques 0MQ.

Le filtre de Kalman fait l’objet d’un module à part, qui se chargerait d’envoyer régulièrement des updates au module de contrôle, pour lui indiquer l’attitude de l’objet.

D’autre part, la caméra fournit un flux vidéo (via l’API Video4Linux), qui sert comme source pour le filtre de Kanade, afin d’estimer la vitesse en translation de l’hélicoptère, fournie ensuite au module de contrôle. On aurait pu envisager d’inclure cette vitesse au filtre de Kalman, mais ce renseignement n’étant pas obtenu au même moment que les données des autres capteurs, il nous semble nécessaire de traiter séparément l’asservissement en attitude et l’asservissement en translation, quitte à utiliser un autre filtre de Kalman pour la vitesse.

Au niveau du streaming vidéo via wifi, je pense qu’on aurait pu se servir de GStreamer afin d’envoyer un flux compressé via Wifi, mais nous avons laissé cette possibilité de côté pour le moment : l’utilisation de la caméra et du filtre de Kanade semblent déjà trop gourmands en ressources pour qu’on puisse se permettre cette fantaisie. Pour le moment, Axel s’occupe de voir s’il est possible d’améliorer les performances, trop faibles pour l’utilisation du filtre de Kanade. Nous verrons donc plus tard si nous pourrons réenvisager de faire du streaming vidéo.

D’autre part, un module de communication en Wifi serait chargé de transmettre des « ordres » reçu d’un ordinateur ou smartphone au module de contrôle.

 

En revanche, il y a un problème dans cette architecture : le module (matériel) radio-fréquence est connecté directement sur le STM32. Or, les ordres reçus via RF devraient idéalement être transmis au module de contrôle. Je vois différentes solutions à ce problème :

- Transmettre les ordres RF reçus à la Gumstix, via l’UART. Mais cela semble être un chemin assez compliqué (et inutile) pour ces ordres.
- Contrôler les actionneurs selon les ordres donnés par la Gumstix, sauf quand on reçoit des ordres RF. Mais cela me semble difficile comme solution (comment faire en sorte que l’asservissement n’annule pas aussitôt les commandes transmises via RF?)
- Déporter la partie logicielle de contrôle sur le STM32, ce qui permettrait en plus de décharger la gumstix d’une partie de sa charge. (après tout, je ne sais pas ce qui m’a poussé à considérer la partie contrôle sur la Gumstix, et pas sur le STM32)

Je pense que la meilleure solution serait plutôt la troisième, mais j’attends quand même de voir ce qu’en pensent les autres.

 

De leur côté, Samuel et Bertrand ont fini les schematics du PCB, et le routage est en cours, il devrait être bientôt fini, comme prévu.