ELECINF344/381

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

Catégories

IRL: Tweets on the laser and DMX

This morning our armadeus board seemed not to want to work properly. We must repare it or use another one.

DMX

We did our first real tests with the DMX yesterday. We are now able to control a light with our DMX board. The information sent to the light can be modified by ZigBee. The ZigBee signal will be generated by a daemon on the armadeus which will listen to requests sent through 0MQ. These features are written but we need to get our armadeus back before performing full tests.
Next step is to use data from the database to select which parameters must be send to the light depending on the tweet we want to display.

Displaying tweets on the laser

Yesterday, we finally displayed a tweet retreived in the database on the laser, with a smooth scroll.
The main daemon, in C, starts by querying the oldest validated tweet in the database, then sends the string to a program that converts it to ILDA frames representing the animation of the scrolling text. As this processing is a bit too heavy to be efficiently done on the board, we decided to offload it on Google AppEngine, which offers great performances ! Whenever we do not have access to AppEngine, the processing is done on the board, but it is really slower. A cache mecanism is being implemented. If you want to use this service, you can find a documentation at irlrose2011.appspot.com. For the moment, it is protected by a password because we need to keep the bandwith and CPU time for our own tests.
Then, the result (a series of ilda points) is sent back to the main daemon through a socket, that tranforms these ILDA points in points that will be displayed on the laser, and passes it through a 0MQ socket to the process handling the laser queue.

IRL is reaching its final rush to the last presentation.

ILDA and Web app
Since the last post we did a lot of tests in real situation, namely with several programs running on the board. We deemed that the operation to translate a text to an ILDA animation tends to be far too slow that’s why we decided to rely on a web app based on the google appengine api for Python. Yesterday, we turned words into action and started to create the web app and a proxy in the card to query the webapp or in case of a failure, redirect request to the embedded slow instance of the program. We did deploy the web app on appspot.com and our first tests tend to confirm that the service is accelerated by a factor of 30 to 60 depending on the load of the board. We did realize a website to present our restfull API to that webapp and we will put it online as soon as possible.

Website
As far as website are concerned, we want to introduce our brand new website. Feel free to comment or share any kind of feedback.

FPGA
We hunted some bugs in our code and yet it works better and we don’t intend to make any kind of fix on it till the presentation.

DMX and additional board
We have contacted TSM and we will be able to try our code with real equipments.
We can communicate with our additional board via Zigbee. We have now to connect this feature with the other parts of the project with 0MQ.

Software FIFO
Our software fifo works, we are putting all the pieces together to make our « driver/conductor/leader » module which will manage all the features of the project.
Today we’ll stick the pieces, it’s a milestone !

IRL : Settings !

In our last article we described some ways to enhance the display of a text scrolling smoothly.
We actually tried several possibilities of settings for the scrolling text and finally found a convenient one (as shown on the video above).

We did some major improvements concerning the speed of the code on the card succeeding in speeding it by a factor of 5. We deemed that a major issue of that program lays on the access time of the memory. Indeed it takes more than 20 seconds to write an ILDA file of a tweet from the ram to the flash. Samuel suggested that we could use a socket to directly send the ILDA file from the python script to the C program in charge of the FPGA communication. In fact, with such a strategy we would avoid the slow speed flash access and be able to send a tweet to the laser around 30 seconds after its validation.

In addition we’re going to add some bit stuffing to make the frames equally populated in terms of points so as to assure a constant frame rate. You can easily notice that disturbing effect on the video above.

In parallel, we’re getting familiar with the DMX protocol and are working on the DMX board.
We haven’t forgotten the software fifo between the C program and the FPGA. We deemed that a zeromq socket would be a interesting solution and we are currently working on it.

IRL : Good news !

As you see, yesterday we were having fun with the laser trying to enhance the performances of our smooth text scrolling show. We now have embedded the whole program and it generates directly the ILDA file on board. We still have some speed issues, namely the program which generates the ILDA files is still pretty slow (it takes more than a minute for a tweet), but our imagination is thriving regarding optimization tricks and yet we gained a significant factor on the computing time.

We are also concerned about the beauty of the text. In fact we noticed a few effects in which we’re focusing on :

- When the laser goes more quickly, the line between 2 given points tends to look like a curve Solution : we are going to fix the derangement by adding several intermediate points between our points, this will be done in C at the end of the display chain.

- When the points are too faraway one from another, the galvanometers tend to be more noisy and we tend to be more worried about the survival of our system. Solution : we reduce the size of the text (so as to narrow the space between points) and insert intermediate points between the characters and at the end of the frame to make the shifts of position smoother.

- When the laser isn’t quick enough, we recognized that the flickering effect is more important.
Solution : we need to speed the laser up.

We did some major improvements on those different points not to mention the complexity issues. Step the text is getting more and more beautiful !

I’m sure you want to know a little more about our FPGA. We have enhanced our previous design by adding a RAM FIFO which will allow us to reduce the load of the CPU. We’re working on the CPU’s side of that program. Anyway, our security module seems to be a bit too sensible and it is triggering more often than expected.

In the next few days we will stress on the development of the DMX card.

IRL : firsts tests with the real laser

Real laser

Today we replaced the oscilloscope by the real laser. As expected, it does not exactly work the same way, but our first test with « The Riddle » is not so bad. You can see it on the video below, it is little as we do not have a lot of space in the classroom. You can see that the image is blinking, this is partly due to our code, but also partly due to the camera sync, and the « real » result is cleaner than what can be seen here.

FPGA design

The new design suggested by our teachers has been implemented, except for the FIFO which for the moment does not use the internal RAMs This will normally be done tomorrow. The FIFO, as it is now sometimes, leads to some bugs that we do not really understand yet. We will also investigate those issues tomorrow. Nevertheless, we have a functional design, the one we used tonight to make the video.

Tweet to ILDA

Concerning the way we will display tweets, Sam suggested us to make a smooth horizontal scrolling. Our first idea was to generate a big ILDA image containing the whole tweet on one line, and to clip it at display time, just before sending it to the laser. It seems that is was not the best way to act. So, we are now trying to generate an ILDA animation corresponding to the scrolling with a Python script. We are on our way and we have yet disclosed a few points of intersert to change in our design to make it work soon.

Web interface

The library we mentionned last time (libmicrohttpd) seems to fit quite well with our needs. It is not a complete Web server, but it is enough to make the card serve a static HTML page and a little REST API to get tweets and validate them. The authentication is for the moment very basic it consists in a « secret » token as segment of the URI. It is not very secure, but it is not our priority at the very moment.

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.

IRL : dure journée …

Nous avons eu beaucoup de doutes ces derniers temps concernant les choix à faire pour avancer. Voici ce que nous avons fait durant les deux derniers jours.


Serveur web

Comme pouvait le laisser penser notre dernier post, nous avons exploré les possibilités offertes par mongrel2.
Il s’agit d’une application qui multiplexe des requêtes http et les recopie sur des sockets 0mq (pour plus de détail : http://mongrel2.org/home).
Nous avons testé mongrel sur nos machines avec succès et il nous semble tout à fait adapté pour résoudre nos problèmes.
Nous avons essayé de le crosscompiler mais sommes confontés pour l’heure à des problèmes.
À terme, nous voulons l’intégrer dans notre buildroot.

ILDA

Nous avons l’ensemble des caractères ISO8859-15 sous la forme de fichiers ILDA. Et nous avons trouvé une nouvelle police qui donne des meilleurs résultats. Nous avons fait un script qui nous donne le numéro du caractère ISO8859-15 entré sur stdin.

Twitter

Nous nous sommes familiarisés avec Twitter et nous réussissons à récupérer les tweets portant le htag #rose2011 directement sur la carte.

FPGA

Nous avons synthétisé et testé sur le FPGA un code utilisant une des rams internes du FPGA et permettant d’y écrire et lire depuis le processeur. Nous sommes en train de parler à la ram SPI qui nous reste (en effet, nous avons mal routé une des deux rams SPI dont nous allons peut-être devoir nous passer).

Authentification

Nous avons clarifié nos idées concernant la manière dont l’authentification sera mise en oeuvre sur la carte. Nous nous repencherons sur la question quand mongrel2 marchera.

IRL : avancées du vendredi

Un point sur les avancées de ce vendredi.

Côté ILDA (Laurent), le programme de conversion SVG -> ILDA a été refondu, il est plus simple et donne de meilleurs résultats. Nous avons réussi à mettre un alphabet dans un fichier ILDA. Il reste cependant quelques problèmes, notamment les lettres qui ne sont pas bien centrées, à suivre.

Du côté du serveur web avec web.py (Caroline), du développement a été effectué sur un PC. On affiche des pages webs avec des informations venues d’une BDD sqlite. La prochaine étape sera de passer le serveur sur l’Armadeus avant d’aller plus loin pour vérifier que la solution est viable d’un piont de vue des performances.

Pour ce qui est des driverset de la communication entre le processeur et le FPGA (Yoann), Sam et Alexis nous ont remis sur la bonne voie après quelques errements de ma part. Du coup la journée d’hier a été peu productive, ça devrait aller mieux aujourd’hui. J’ai par ailleurs consacré pas mal de temps à la lecture de Linux Device Drivers.

IRL : Mise en marche de l’armadeus, et autres

Fin des PCB : Nos PCB pour la carte additionnelle laser et la carte DMX ont été finis et envoyés vendredi soir. Pas de message d’Alexis, bonne nouvelle…

Installation de l’armadeus : nous avons pris possession de l’Armadeus APF27-dev en fin de semaine dernière, et nous avons commencé à nous en servir. Pour l’instant nous avons :

  • Compilé un noyau sur lequel on a réussi à booter
  • Compilé un rootfs (plusieurs fois pour ajouter quelques fonctionnalités au fur et à mesure), en version UBIFS pour accélérer la vitesse de montage des partitions au démarrage (sur conseil d’Alexis)

Notre carte dispose maintenant d’un serveur SSH (pratique pour travailler à plusieurs dessus), et d’un serveur web boa (qui parfois donne des erreurs au démarrage, on cherche) grâce auquel nous avons pu accéder à une page web hébergée sur l’armadeus. Nous avons également testé un Hello Word en CGI, en bash pour commencer, puis en C++.
À ce propos, nous nous interrogeons sur le langage à utiliser pour l’interface web côté serveur. Nous hésitons entre Python plus facile et adapté (mais buildroot ne propose pas le mode CGI, peut-être est-il par défaut) et du C++ à l’aide de libcgicc (probablement plus rapide mais plus source à embêtements).

Par ailleurs, nous pensons utiliser sqlite pour associer des masques DMX, des images et animatiosn ilda à différents mots-clés que l’on pourrait extraire des tweets, ou à différentes ambiances prédéfinies. Nous ne sommes pas encore sûrs d’utiliser une base de données, c’est à étudier plus en profondeur.

Framebuffer : on nous avait soufflé l’idée d’utiliser le framebuffer de Linux pour se servir du laser comme écran, cette idée était trop complexe et mal adaptée. Sam et Alexis nous ont proposé une autre idée plus abordable (mais qui restera comme du « bonus » et ne sera pas un objectif principal) qui serait d’afficher la sortie d’une console série. Laurent a fait un petit script qui construit un fichier ILDA simplifié au fûr et à mesure des saisies d’un utilisateur. Cette idée paraît donc réalisable, on la garde pour plus tard.

Alphabet ILDA : nous avons besoin d’une bibliothèque de fichiers ILDA (ou ILDA simplifié X, Y, on/off) contenant les caractères affichables par notre laser. Comme Alexis nous l’a conseillé, nous sommes parti d’un alphabet SVG que nous parsons pour aboutir à notre format ILDA simplifié. Nos essais sur une dizaine de lettres sont concluants.

FPGA : on a pris en main l’IDE et synthétisé un exemple (blinking LED) de la doc. Nous pensons l’avoir flashé  correctement sur le FPGA, cependant l’alimentation de la LED requiert le branchement de deux pins de l’Armadeus, nous attendons l’avis de Sam ou Alexis pour être sûrs de ne rien griller. Par ailleurs, Laurent a réalisé un module en Verilog qui gère la communication avec les mémoires SPI, il reste un détail à modifier mais l’essentiel est là et le code est sythétisable.

IRL : Avancées de la journée

Aujourd’hui nous avons eu l’occasion de rencontrer un étudiant qui a travaillé il y a deux ans sur le projet Laser.
Nous lui avons expliqué l’architecture de notre projet et avons récupéré une partie des sources de son projet.

Nous avons mené des essais avec les cartes de TP concernant la transmission par zigbee des masques pour le flux DMX. Ces essais ont été concluants : nous arrivons à transmettre et recevoir sans erreurs différents masques DMX et à les stocker en RAM.

Nous cherchons une police adaptée au laser et sous forme de fichiers au format ILDA pour pouvoir afficher du texte sur l’écran. Nous avons constaté que l’équipe de l’année dernière a réalisé des caractères au format ILDA qui ont un bon rendu avec notre afficheur ILDA.

Nous avons par ailleurs décidé en suivant les conseils d’Alexis d’utiliser une RAM externe pour notre FPGA (ram SPI 256Kbits code radiospare : 666-8148).

Nous sommes en train de réaliser les PCB, de faire des simulation en Verilog et de réfléchir au format de stockage des informations à afficher par le laser dans le FPGA. Nous attendons l’Armadeus dont nous disposerons peut-être demain.