Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

PuLSE : dernières avancées…

Depuis deux jours, le problème concernant la fenêtre tcp est réglé. De plus, le serveur http fonctionne maintenant correctement ce qui nous permet d’envoyer des fichiers à notre carte afin de les sauvegarder sur la carte SD. Reste maintenant à gerer les accès concurents à la carte SD et à parser correctement les requetes PUT

Twitter

Je viens de finir le programme en python qui sera chargé de récupérer les nouveaux tweets, de créer le fichier ilda correspondant et de passer au suivant si on valide, juste de passer au suivant sinon.

Je n’ai plus de problème de caractères, ils sont bien encodés en utf-8. Avec ce que j’ai fini ce matin, on aura pas de problème non plus pour les afficher avec le laser.

Il reste juste à faire le lien de ce programme avec ethernet. On voit ca demain.

SVG to ILDA

L’idée était d’avoir un alphabet complet et non pas seulement les 26 lettres de l’alphabet en majuscule! J’ai donc modifié le nom des fichiers, ils s’appellent maintenant avec le code hexa de la lettre qu’ils contiennent.

De plus il a fallu améliorer le parseur svg to ilda pour qu’ils puissent reconnaitre maintenant un « è » par exemple ce qui n’était pas le cas avant.
Ca m’a pris pas mal de temps parce qu’il a fallu que je reprenne presque intégralement mon code (premier script en python de ma vie…) puis que je l’améliore.

Mais maintenant tout marche bien, il me resterai éventuellement quelques caractères à ajouter mais ca serait vraiment pour faire beau parce que là on tout ce qu’il faut pour écrire en français!

PuLSE, j-5

Aujourd’hui nous avons trouvé le problème qui survenait lorsque nos deux grandes tâches (le serveur http et la tâche de gestion des fichiers) étaient connectées. Nous avons donc pu lire des playlist codées en dur dans la page web.
Ce soir je me suis mis à la page web définitive. Après quelques heures de débugage voici le résultat (presque terminé) :

On pourra y mettre des répertoires complets, ou bien des fichiers. La liste des fichiers sera générée dynamiquement, et a priori ca sera la seule partie générée automatiquement. Du coté du serveur, Etienne et Thibaut ont fait pas mal de débugage (y compris sur la carte SD et sur l’utilisation des outils python pour génerer les requetes) et ont implémenté le PUT.

Demain, j’essaierai d’apporter de quoi faire une vidéo (Samuel en avait pris une avant les vacances mais je ne l’ai jamais revue d’ailleurs)

ILDA

Alors aujourd’hui j’ai repris mon programme Python pour l’améliorer (il était assez sale à certains endroits et notamment j’utilisais un bout de code en C ce qui m’empêchait de le faire évoluer). Je n’ai pas tout à fait fini mais ca devrait plus être trop long.

Ce qui va me permettre de gérer un alphabet bien plus complet ce que j’ai pu faire jusqu’à présent.

J’ai aussi regardé niveau Ethernet ce qu’on pouvait faire avec Etienne, mais sans grand résultat. Une fois que tout ca marchera bien, il ne restera plus grand chose à faire pour finir le programme Python (peut être pas très beau esthétiquement…)

PuLSE, j-6

Actuellement on a une page web qui offre la possibilité d’envoyer une playlist, et quelques modes de fonctionnement (diaporama, lecture en continu, éventuellement lecture aléatoire de fichiers sur la carte). On a un serveur http qui n’est pas encore compatible avec le protocole http, on préfère dans un premier temps mettre notre protocole basé sur des requêtes http (get, put, post, delete) et le rendre conforme au protocole http ensuite (notemment dans le cas des gestions d’erreurs, en s’appuyant sur le serveur de Microchip). En particulier, en définissant à la main les contenus des requêtes on est arrivé à avoir des requêtes plus concises que celles générées dans les formulaires de firefox). Actuellement le protocole lit la playlist envoyée. A cause d’un bug dans le chargement des fichiers on n’a pas pu faire de test avec le laser, mais on y était presque.

Un petit apreçu de la page web (elle est un peu à revoir au niveau du style maisce n’est pas la priorité pour le moment)

Serpentina : début des bons mouvements

Jeudi :

La calibration des cartes (trouver le degré neutre de chaque servo de toutes les cartes) a été fini et le code a été changer pour prendre en compte le fait que les servos verticaux sont alternés toutes les deux cartes (degré positif -> la vertèbre monte, degré positif -> la vertèbre suivante descend).
À partir du moment qu’on a eu une interface pour contrôler individuellement les servos, Flavia et moi avons aussi corrigé la relation entre l’angle de mouvement et la largeur du pulse (avant le mouvement du serpent ne correspondait pas à ce qu’on voulait).
Cela corrigé, on a commencé à faire des tests de déplacement avec le serpent. Et, finalement il a bougé. Et après des corrections, on a pu le faire marcher en avant, en arrière et a le faire s’arrêter et retourner à une position de reset (tout droit et plat).
Le soir, j’ai commencé à vérifier les envois des messages pour faire le virage du serpent.
Ah, le bootloader arrive bien à flasher les dix cartes. On a eu un problème de temps qu’il mettait pour tout finir mais c’était notre carte du TP qui le retardait. Sans aucun affichage dans le LCD, il met à peu près une vingtaine de secondes pour flasher toutes les dix cartes en parallèle.

Vendredi :

L’après-midi, j’ai mis quelques heures pour trouver un problème dans notre bootloader. D’un coup, il ne marchait plus. C’était une configuration du can, mais comme rien par rapport à cette configuration n’avait été changé dans notre dépôt, c’était dur de le trouver. Le bizarre c’est qu’il marchait avant. Ensuite, j’ai continué à travailler sur les virages. J’ai vu que les messages envoyés étaient ce qu’on voulait, mais le robot ne marchait pas.

Samedi :

Ce matin, j’ai pensé à une autre solution pour le virage. Au lieu de le tourner en une position X fixé, la tête du serpent tourne quand elle reçoit le message TURN et ensuite elle envoie un message à la vertèbre suivante. Celle-ci attend quelques instants, tourne et envoie un message à la vertèbre suivante. Ça jusqu’à la dernière vertèbre. Après des corrections, on a réussi à faire des virages dans le deux sens (quand le serpent marche en avant et en arrière). Cependant, on a encore des erreurs : parfois, les cartes se bloquent. Je reviens à ça ensuite.

ILDA et Défilement

Alors aujourd’hui je me suis attaqué au défilement qui était en réalité plus compliqué que ce que je pensais.

J’ai continué en python en réutilisant quelques binaires écrit en c et tout marche bien ce soir. On fait des tests demain, maintenant que la vidéo marche!

Mais je suis confiant, j’ai pu testé avec gnuplot que ca donne.

Twitter/ILDA

Alors ce matin, j’ai amélioré mon parseur svg pour pouvoir transformer tout un alphabet en un coup et pas lettre par lettre.

J’ai ensuite fait un nouvel alphabet avec plus de points. Du coup on va pouvoir tester avec ce nouvel alphabet pour voir si l’affichage en est amélioré.

J’ai ensuite continué le programme qui maintenant scrute twitter, met le tweet dans la liste de lecture et crée le fichier ilda correspondant quand nouveau tweet il y a.

J’ai rajouté aussi la possibilté d’écrire directement du texte, il est mis dans la liste de lecture et le fichier ilda correspondant est crée.

Demain je fais défiler du texte pour pouvoir afficher un tweet en entier (140 caractères) et je regarde comment faire pour envoyer les informations à la carte (fichier ilda par exemple).

carte SD, c’est pas encore ca

Je suis reparti ce soir de la version 3.1 de la bibliothèque ST pour cartes SD. J’ai pu revenir à peu près à l’état où on était avant de passer sur cette version, c’est à dire que j’arrive à lire des blocs. Thibaut et Etienne ont aussi essayé cet après midi et n’ont pas eu plus de résultats.

Je me suis basé sur le code d’un projet fourni dans la bibliothèque ST, et bien que je ne fasse que des opérations simples j’ai pas mal de problèmes. En particulier la carte SD refuse (ne répond jamais) la commande qui la fait passer en mode 4 bits, et j’ai à la première lecture de bloc un CRC fail, qui disparait magiquement si je refais une lecture de ce même bloc. J’ai regardé le projet circle qu’Alexis nous a donné, et je n’ai pas noté de différence entre leur séquence d’initialisation des horloges et la notre.

Bref,pas de changements notables depuis le passage à la version supérieure.

La suite plus tard dans la matinée…